chore(ci): migrate disabled Trivy scan to reusable Grype workflow - #18
Conversation
Replace the per-repo (if: false) Trivy security-scan job with a caller of SupportTools/ci-runners' reusable grype-scan.yml, keeping it opt-in/non-blocking (if: false + blocking: false) since the KubeTTY image is still too large to scan practically in CI. Also swaps the local best-effort validate-pipeline-local.sh trivy checks for their direct grype equivalents, and adds an empty .grype.yaml (no .trivyignore existed previously).
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 902a00bf31
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if: false # Disabled - KubeTTY image too large for Grype to scan in CI (same reasoning as the prior Trivy job) | ||
| uses: SupportTools/ci-runners/.github/workflows/grype-scan.yml@main | ||
| with: | ||
| image: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}@${{ needs.build.outputs.image-digest }} |
There was a problem hiding this comment.
Because this job calls a reusable workflow, jobs.<job_id>.with.<input_id> expressions are limited to the github and needs contexts per GitHub's workflow syntax, so the newly added ${{ env.REGISTRY }} / ${{ env.IMAGE_NAME }} references make .github/workflows/pipeline.yml invalid at parse time even though the job has if: false. Every push or PR that loads this workflow will be rejected before CI jobs are scheduled; hard-code this image prefix or pass it through an output from a needed job.
Useful? React with 👍 / 👎.
pipeline.yml is pull_request-triggered, and the private-repo reusable grype-scan.yml fails to resolve at workflow-load time on pull_request, failing the entire run at startup (0 jobs) even with if: false (resolution precedes if). Replace the reusable uses: with an in-line anchore/scan-action@v6 step, keeping the job disabled (if: false) as before (image too large to scan in CI).
1 participant
Summary
if: false) per-repo Trivysecurity-scanjob in.github/workflows/pipeline.ymlwith a caller of the org-wide reusableSupportTools/ci-runners/.github/workflows/grype-scan.yml@mainworkflow, for consistency with other repos.grype-scanjob stays effectively opt-in/non-blocking: it keepsif: false(same reason as before — the KubeTTY image is too large to scan practically in CI) and setsblocking: falseon the reusable workflow, so it will never gate the pipeline even if enabled later.needs: [build]wires it to the build job and it scans the exact image built there via${{ needs.build.outputs.image-digest }}(by digest, so it always matches the pushed image regardless of tag scheme).needs.security-scanreference in the (also disabled,if: false) "Verify security scan passed" step indeploy-productiontoneeds.grype-scan.aquasecurity/trivy-actionstep (SARIF scan, blocking scan, SBOM generation) — no trivy-action references remain in the workflow.validate-pipeline-local.sh: swapped its local best-effort Trivy checks for the direct Grype equivalents (grype "$IMAGE_TAG"for the informational pass,grype "$IMAGE_TAG" --fail-on criticalfor the blocking pass) — this was a trivial, obvious command swap, so no TODO was needed..grype.yaml(ignore: []) since no.trivyignoreexisted previously; this matches the reusable workflow's defaultconfiginput.Notes
grype-scanstaysif: false, it will not run on this PR — that's expected/by design (mirrors the prior Trivy job's disabled state). Validated YAML withpython3 -c 'import yaml; yaml.safe_load(...)'and confirmed shell syntax withbash -n.Test plan
python3 -c "import yaml; yaml.safe_load(open('.github/workflows/pipeline.yml'))"passesbash -n validate-pipeline-local.shpassestrivy-actionoraquasecurity/trivy-actionreferences in.github/workflows/Update: switched to in-line anchore/scan-action (grype engine)
KubeTTY
pipeline.ymlispull_request-triggered. The org reusablegrype-scan.yml(private-repo reusable workflow) fails to resolve at workflow-load time onpull_request, which 0-job-startup-failed the entire pipeline run even withif: false(GitHub resolves the reusableuses:before evaluatingif:). Replaced the reusable job with an in-lineanchore/scan-action@v6step, kept disabled (if: false, image too large to scan in CI) exactly as before. An in-line action has no load-time resolution problem, so PR CI is no longer broken.